In conventional engineering disciplines, architects consider how a building will be used when laying out overall specifications for the building. These specifications are then transformed into a set of standard construction elements. Engineers provide specifications for these elements to be used in constructing the building. Construction groups use appropriate technology and tools to actually construct the building. As an example, in a typical building project, architects use standard elements (viz., simply-supported beams, cantilevers, domes, and columns) to create an overall structure that satisfies the functional and aesthetic requirements of the building. Engineering groups use standard engineering elements (viz., I-beams, trusses, etc.) to translate the architectural specifications to engineering specifications. Construction groups use the engineering specifications along with the recommended technologies, materials and tools to complete the project (viz., concrete mix, steel, wood, welding equipment, etc.).
There have been many software engineering aids and ideas that attempted to solve the issue of structuring, storing and managing specifications created during the different phases of software lifecycle. Recently, some approaches have appeared to create an integrated approach for managing software lifecycle by integrating these islands. All these approaches suffer from the following issues: difficulty in defining standard elements to model the information captured in these various phases, difficulty in understanding the relationship between these elements while implementing the various phases, and difficulty in creating an integrated process around a central model.
Issues arise due to the fact that the representation of specifications captured across these stages need a common thread or translation semantics. Since diagram elements are varied even in a single phase and view and usage of such elements are also varied, evolving a common data model has never been achieved. The difficulty is compounded by the fact that the class of information systems specified (viz., business systems and real-time systems) require different representation mechanisms owing to the differences in implementation interpretation. Conventional attempts end up as patchwork of various aids integrated poorly.
Other requirements that need to be addressed in the current approach include the peripheral activities in the software lifecycle. These relate to configuration management, analyzing impact of changes to be made, project-management-related activities dealing with estimation, planning and control and rolling out the product and creating access profile. This requires standardized work product structure and the relations between the various elements of the work product. Lack of an integrated representation of the product structure severely affects the ability to perform all the related activities in the context of the work product.